IBIS Macromodel Task Group

Meeting date: 30 May 2023

Members (asterisk for those attending):
Achronix Semiconductor:       Hansel Dsilva
Amazon:                       John Yan
ANSYS:                      * Curtis Clark
                            * Wei-hsing Huang
Aurora Systems:               Dian Yang
Cadence Design Systems:     * Ambrish Varma
                              Jared James
Google:                       Hanfeng Wang
                              GaWon Kim
Intel:                      * Michael Mirmak
                              Kinger Cai
                              Chi-te Chen
                              Liwei Zhao
Keysight Technologies:        Fangyi Rao
                              Majid Ahadi Dolatsara
                              Stephen Slater
                              Ming Yan
                              Rui Yang
Marvell:                      Steve Parker
Mathworks (SiSoft):           Walter Katz
                              Graham Kus
Micron Technology:            Justin Butterfield
Missouri S&T:                 Chulsoon Hwang
                              Yifan Ding
                              Zhiping Yang
Rivos:                        Yansheng Wang
SAE ITC:                      Michael McNair
Siemens EDA (Mentor):       * Arpad Muranyi
                              Randy Wolff
Teraspeed Labs:             * Bob Ross
Zuken USA:                  * Lance Wang

The meeting was led by Arpad Muranyi.  Curtis Clark took the minutes.

--------------------------------------------------------------------------------
Opens:

- Note:  The meeting scheduled for May 23rd was not held.

-------------
Review of ARs:

Arpad:  Send an email announcing the ATM task group's recommendation that SPIM
        continue on the track toward being included in IBIS.
        - Done.

--------------------------
Call for patent disclosure:

- None.

-------------------------
Review of Meeting Minutes:

Arpad asked for any comments or corrections to the minutes of the May 16th
meeting.  Ambrish moved to approve the minutes.  Lance seconded the motion.
There were no objections.

--------------
New Discussion:

AMI Support for [Test Data]/[Test Load]:
Michael said he thought providing Test Load information in the AMI context would
be straightforward.  However, he thought Test Data in the AMI context would
would require more effort.  In addition to providing waveforms representing
impulse responses or blocks of GetWave data, we would have to provide data such
as the unit interval and sample interval (i.e., samples per bit), which
typically are set by the user.  Michael described three types of data we need to
provide to define the Test Data conditions:
1.  Waveform data representing the inputs and expected outputs from the AMI_Init
    or AMI_GetWave functions.
2.  Data such as the unit interval and sample interval, which are typically
    configured by the user and passed to the model via the tool.
3.  A specification of the specific settings of the AMI parameters under which
    the expected output was generated.
    
Michael said one initial question for the group was whether we should introduce
a new format for the new types of data required or attempt to adapt the existing
AMI parameters structure to accommodate the new data.

Arpad said the existing [Test Data] includes waveforms, and he asked how this
would be different.  Michael said the existing [Test Data] provides information
at the pad or pin.  For AMI, we want to provide reference waveforms to compare
to the filtered waveforms returned by the AMI model's Init or GetWave calls.

Arpad referred to his recent presentation on the possible interactions between
the block size of the AMI_GetWave call, which is defined by the EDA tool, and
the adaptation time constant of an AMI Model that continued to adapt its Output
thresholds and sampling offsets even after Ignore_Bits.  He said there was an
interaction between a tool chosen value (block size) and the Model, and he had
suggested that it might be helpful to give the model maker a way to specify the
recommended block size.  He said information we specify in Test Data might be
a helpful step in that direction.

Arpad asked what we might specify for golden information.  He asked if Michael
was considering contour information or eye plot information.  Michael said he
was strictly considering waveforms, as contour plots and eye diagrams are tool
specific proprietary processes that are not standardized.  He wanted to stick to
raw waveforms that are returned from the model.

Ambrish said that given fixed parameter settings, unit interval, samples per
bit, etc., different tools should end up producing the same output waveform for
a given input waveform.  He said he would prefer to use the existing AMI
parameter tree structure.  Ambrish noted that the details will be important.
For AMI_GetWave, for example, we may have to provide a comparison waveform
for the first block of data after Ignore_Bits.  Michael agreed that we could
use the existing AMI parameter structure for specifying the AMI parameter
settings, and he agreed that AMI_GetWave testing might involve additional
details and assumptions that we have to make.

Michael summarized the goal of the proposal:
The model maker provides the information.  They specify the test load, test
settings, and the input waveform.  If the simulation ends up with a different
filtered waveform at the output than the model maker expected, there is a
problem.

Arpad said that he often has to go through this process manually to provide
correlation information to customers.  In general, one might only have a .pdf
from the model maker or customer with images of contours, waveforms, eyes, etc.
Ambrish agreed that the process is not currently standardized.  Wei-hsing
noted that given the same .sNp different tools often produce different impulse
responses.

Arpad observed that in the AMI_GetWave case the output waveform is highly
dependent upon the overall bit pattern.  One tool might use a different seed,
for example.  Ambrish agreed and said we need to provide the exact bit pattern
as part of the input definition.

Michael said he would take the suggestions and work on the proposal.  He said
his preference was to provide the new information in a separate file.  He noted
the suggestion to use the existing AMI parameter tree structure, and he noted
Ambrish's suggestion that everything including waveforms, etc., should be plain
text format.

Proposal for a new keyword:  [Clock Group] 
Michael recalled that IBIS 7.1 introduced the [Clock Pins] keyword, which
allows the model maker to indicate pins that have a clock pin and clocked pin
relationship.  Right now, however, the only type of relationship that can
be specified is "Unspecified".  The point of the [Clock Group] proposal is to
start defining the clock relationships.  In addition, the current [Clock Pins]
keyword makes it hard for the model maker to handle cases where a DQS strobe
might be configured x4 or x8 DQ lines, as might be the case for DDR controllers.
Michael said work on the AMI Test Load and Test Data had been taking precedence
over this proposal.

Arpad asked whether [Clock Group] might be considered a higher priority given
the pace at which DDR simulation support is advancing.  Michael said he wasn't
sure, and he thought there might be existing proprietary solutions people were
using.  Arpad and Michael left it as a homework assignment for people to think
about which proposal should be given higher priority.

- Michael: Motion to adjourn.
- Curtis: Second.
- Arpad: Thank you all for joining.

New ARs:

None.

-------------
Next meeting: 06 Jun 2023 12:00pm PT
-------------

IBIS Interconnect SPICE Wish List:

1) Simulator directives
